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(54) Secure fie system 

(57) A method and apparatus that allows a compu- 
ter system to trust both program and data files without 
the Intervention of the user and without the posstoSrty of 
circumventing the model of trust A file system incorpo- 
rates two levels of validation for programs and data. A 
first level of validation speeffiea sources that the user 
has decided are trustworthy or untrustworthy. A second 
level of vafidatron speefflea sources that the system 
Itself considers trustworthy or untmstworthy. For data to 
be acceptable, It must be acceptable to both levels of 
checking. In addition, both the user and the system can 
spedfy multiple acceptable signatures and further 
allows various ones of the multiple signatures to have 
different levels of access to the system. 
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Description 

HELD OF THE IMVEMTKIM 

This application relates to operating systems and, s 
mor© particularly, to a f il @ system that v&tftatss an entity 
attempting a ff3e access bsfare aEowing tho entity to 
perform file operations. 

mcKGwemwo of tme nr^rWm « 

in recent years, the internet has become extremity 
popular. Using the internet, users can dcamloEd fifes 
Into the rrtejncry of their computers easily end cheaply. 
Ois problem with such a process Is that Sha isssr has rto » 

of knowing whether Eh© party supplying the soft- 
ware 5s trustworthy. Software suppled from uffirusted 
sources can contain unexpected "bugs' ami might even 
be ccmplsteSy different from th© software the uassr 
expects to rocorva Foj example*, software from so 
untrusted sources may contain a computer V&U3 that & 
not detected until the eoftamro Is executed. 

In feefl. such problems can arise urith any software 
or data obtained from outside sources. Computer pro- 
grams and computer data fites are ncrms% s&red on Jtf 
computer systems wtfcout th© capaftfity el automati- 
caDy ensuring that programs sstd da& giro 1) authentic 
and 3) unmolested. ConvenSonal methods o? ch©ct&}g 
for euttcsn&cJty and nonoorruptioft require action on tho 
part of human beings, AppJieatEon programs verfiy data so 
by foced chscfcsujTB, both with and wfthcut c?yplo- 
uja pltc assioranod. What is needed is a truly automatic 
and transparent method off checMng and autfienScafing 
software ond data in a computer system. 

SUMMARY OF THE INVENTION 

the pr@S£nt i mention overcomes fh© problems and 
dte&&/anaaiQ©s of the prior art by providing a meflicd 
and apparatus the* allocs a computer system Co trust <& 
both program and data files without fre intervention of 
the user and witfi a decreased possib^ty of circumvent- 
ing the model of trust 

A preferred embodiment of ths present fnv@n3on 
includes two levels of validation for p r o g r& n m and data, 
A first level of vattdatson ^ectfies sources that the user 
has decided are trustworthy (or not trustworthy). A sec- 
ond level of validation specifies sources ftat the system 
itseff considers trustworthy or untrustworthy. For data to 
be &cceptab3© ( it must be acceptable to both levels of bo 
chedeng. Thus, for sxampSe, if the user decidos to 
accept aB data from entity "A°, but the system has 
decided not to accept all data from entity °A," the file 
system would not store data from entity "A/ Asa further 
example, if the user has decided to accept no data from ss 

but the system has decided to accept aD f^fa from 
"B°, then no data from wou£d be stored on the sys- 
tem. 



fn addition, a preferred ernbc<5rnen! of the present 
invention allows the user and the system to specify mul- 
t$pla acceptable signatures and further allows various 
ones of the multiple signatures to have different levels of 
occoss to the system (Le., deferent permissions). A pre- 
ferred embodiment the present invention can be imple- 
mented so as to be transparent to she user snd to co- 
erast wfth existing ftto systems. 

in accordance with tha purpose o$ the invention, as 
embodied and broadly described hereat, a preferred 
embodiment of the present Invention c$ a method of per* 
forming a file gsecoss, comprising flie steps, performed 
by a data processing system having a memory of: 
receMrtg an indication fliat an enflty desJros to perform 
a file access operation cm afilQ o?tfr® data processing 
system; obtaining an affidavit of the foe; checttng that 
the affidavit is acceptable in accordance with a user sig- 
nature data structure stored fcn the memory: checking 
that the affidavit is acceptable in accordance with the 
system signature £&t& structure stored in the memory; 
and e! Jewing the ft!© access operation whan flie aff idsvrt 
is acceptabte in accordance with both the user signa- 
ture c^t structure and the syi^om signature data struc- 
ture. 

Cn fusthe? accdtSartcs urith tfcg purpose c3 frie inven- 
tion, as embodied and broadly descr&ed hcigtn, a pre- 
ferred sTrtbodment of the prasont invenfton te a m^hod 
of cresting $ secure fite, comprising the steps, per- 
fermsd 1^ a data processing system tmvmg a memory, 
of: receMng an imftcsgion tot an err^ desires to per- 
form a fffe a cc ess operation on a file of 9>& data 
processing system; obtaining a private key of die enfity , 
receiving <&ta c? Qie fBe to be created; determining a 
checksum of the file; ertcrypftng ifr? cttsdQum using ^e 
private hoy; end creating &e file and ami associated affi- 
davit that Includes the encrypted checteum 

tn further accoTctance with the prosant inv©nticn, as 
embooled and brosdly c^senbed hereon, a prsfemsd 
emboolrnem of the present enventon is: a signature 
data ^ructure stored in a memory of q data pjeeessing 
system, comprising: a first ©ntfty field storing a namo of 
an entiiy trusted to perform a fo® access; a first public 
key field storing a puMto key of the first entity; a second 
entity field storing a name of an entity trusted to perform 
a file access; and a second public key field staring a 
public hey of tho second entity. 

Advantages of the invention will be set forth in part 
in die description which follows and in part wOl be obvi- 
ous from the description or may be learned by practice 
of tho invention. Advantages of tfts invention will be real- 
ized and attained by a combination of the elements par- 
ticularly peonted out in the appended claims and 
Equivalents. 

The accompanying drawings, which are ricorpo- 
rated in and constitute a part of this specification, 2lus- 
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trate Severn) embodiments of tfie Invention and. 
tog other with the description, serve to e^tain 9)3 prmci* 
pies Off the nrttfQnfa'on. 

Fig. 1 is a Week diagram of a computer system in 
accordance wfth a preferred embodiment of the present 
invention. 

FEg. 2 is a bW* dagrami showing a data flow of a 
preferred embodiment of the present Invention. 

Fig. 3 shows on example of a user sfgnauc© data 
structure or a system signature data structure cfl Hg. 1. 

Figs. 4(a) and 4(b) are flow charts showing how 
files are chscked against she user signature data and 
t!he system signaturo dats- 

Rg. 5 Is a flow chart of steps used to create signed 
files in a preferred embedment of tSte present invention. 

Fig. 6 is a btock diagram of another preferred 
embodiment of the present invention In wKch the major- 
ity of the operating system must be verified befar© the 
system can be booted. 

Reference w3l now be matfe to detail to tfie pre- 
ferred embedments c3the invention, examples of which 
an© illustrated in ths aooompariynigi drawings. Whgretfer 
possible, the same reference numbeaa be used 
throughout toe drawings to refer to fih© same or lite 
parts. 

Rrj. 1 1s a block diagram of a computer system 100 
in accordance wffli a preferred ernbeelmsna off the 
present) crwerttion. Computer system ICO is connected 
to line 106, which can be, tor example, e LAN, a WAN, 
or on internet connection. Line 108 can also represent a 
wireless connection, such as a cellular network connec- 
tion. 

Computer system 100 includes a CPU 102; a pri- 
mary storage 104; tnput/ou2put linos 105; on input 
device 150. such as a keyboard or mouse; and a display 
devece 160, such as a display terminal. Primary storage 
104 can include any type of computer storage indudmg. 
without GmftafSon, random access memory {RAM), read- 
only memory (ROM), and storage devices wWch Include 
magnetic and optical storage madia such as magnetic 
or optica! disks. Computer system 100 further includes 
an Input device 161 tor roading a computer us&blo 
medium 162 having computer readable program code 
means embotfed therein, tnput device 1@1 is, for exam- 
ple, a dsk drive. 

Primary storage 104 includes a date, structure 120 
containing user signatures and a data structure 122 
containing system signatures, as discussed beSow In 
connection with Ftg. 2. Memory 104 also includes sig* 
nature checking software 124. wrcch fe also osscussed 
below. 

A person of orolnary sWtl in the art wilt understand 
that memory 104 also contains additional crtfermatton, 
such as application prog rams, operating systems, data, 



etc, which are not shown in the figure for the sake of 

clarity. It wk0 be understood by a person of ordinary skill 
in the art that compt er system 100 can ateo indude 
numerous elements not shown in the figure for the sake 

5 of clarity, such as additional <Ssk drives, keyboards, dis- 
play devices, network connectors, adtEbonal memory; 
additional CPUs. LANs, Inpuifoutput fries, eta A pre- 
fefYSd ^mboduvont of the invention runs under flto Sola- 
ris operating system, Version 2.3 and higher. Solaris is 

10 a registered trademark of Sun Microsystems, Inc. 

Rg, 2 is a block rJagram showing a data flow In a 
preferred embodimortt of tho present invention. Re 202 
has an associated affidavit 203 (also called a "crypto- 
graphic Affidavit-! As a file 202 e$ received by the sys- 

1$ tern, Its affidavit is checked against tite signatures In the 
user signature data structure 1120 and in the system sig- 
nature data structure 122. The fOe must pass both tests 
before It can be stored by Sie system. 

Rte 202 contains two parts: a file portion 204, 

20 which contains executable programs c? data, and an 
affidavit portion 206, which contains an encrypted 
checksum 210 and other adnrtirt&ratfve data 208. 
AoVrcnsstrativB date 208 freclucCss the red identity of the 
creator of the affidavit, identifiers or pointers to other 

23 associated affidavits, dates and times of creation artd 
gspoation of the affidavit, end identifies co-signers of 
foe affidavit tn acme implementations, affidavit 206 Is a 
part of ffle 302 and in ofter CmpJemartJaGons, affidavit 
203 is a separate M& that is associated with file portion 

so 200. For emampla, affidavit 206 can be incorporated frrto 
seme f Q e formate ©s a comment Kn©. Other fa© CcjtohIs 
may bBow the acScdavit to be ctosery coupled to the 53© 
portion 204 tn some toicwn marurar. 

Fcg. 9 sfto&s an example of a signature data struo- 

3$ fur© of Fig. 1. Both user gcg rart uro data structures and 
system signature data structures preferably tewe the 
same crgantration. and the formst of Ftg. 3 is used for 
both. Tho leot signature data structure represents 
sources that the user has Indicated are trustworthy and 

40 foe system signature data structure represents sources 
Chat the system considers to b® trustworthy, tn frie 
example, each entry En the signature data sffucaure has 
a name of a trusted entity 302, a type 304 of the entry 
(e.g. t single antry or irttSrect database entry), a pubSc 
key 306, and a series of values 308 intBcating the type 
or typos of permissions tho entity has for the system 
(e.g„ create, delete, read, write, execute, ete.). Every 
file access (e.g„ every file open and delete operation) i& 
checked egaenst bo^i the user and system data struc- 

bo tures by the file system before the f He access is aaowed 
by the file system. 

Rgs. 4(a) and 4(b) are flov* charts showing how 
ffios aro d^edoed against &ig user signature o^ta and 
the syGtem signature data by the file system. In the pre- 
ss ferred embodiment, all files received by the system from 
an outside source must Inctudo on affidavit Similarly, 
each file created and stored by the file system must 
have an associated affidavit In some implementations. 
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the affidavit is a part of the fDe, In other implementa- 
tions, me affidavit is asaccaBied with the file. Thus, the 
aff idavii of a file is checked whenever a fUe operation is 
performed for the fa 9, For example, the affidavit is 
checked the file is erected or Seeded into memory. 5 
The affidavit also is checked when the fit® is read from, 
written to, or deleted. Such a process serves two goals: 
1) to protect the ffle system from outsiders who wish to 
compromise files and 2) to protect users of She system 
from accessing or relying on ffles that have been tarn- 10 
pered with. R will be understood by persons of ojtEnary 
sWD in the art that the steps of Figs. 4(a) and 4(b) are 
performed by CPU 102 of Fig, 1 eracuting instructions 
of the file system/operating system tfwt et© stored in 
memory 104. The steps of Figs, 4(a) and 4(b) preferably 1S 
ere performed each time a file access is requested 

In stop 402 of Fig 4(a). the f3e system gets the 
encrypted checksum 206 associated wtfi the fDa. in 
step 404, the ffle system repeats ths calculation of the 
chedxum Cor the file using any known checksum zo 
method was used to determine tho affidavft Steps 
era repeated for each entry in 3ra use7 signa- 
ture data strucsurs (or unto a match is found). 

In step 403, fre file system decrypts tho encrypted 
checteum 214 of the affidavit uslrg me pub£c tesy of the 25 
current user signature dsfie structure entry. Because the 
affidavit was created wfth the enfihys private toy, 
decrypMon o? the affidavit using the entity's cwroct pub- 
Go toey should yield a decrypted checksum tor the f Be. 
Decryption using other pubfee kays should yield an 90 
tacofreot checksum. 

% in step 410, tho decrypted checksum matches 
the checteum determined In step 404, then the affidavit 
raprssanSs en emrty considered trustworthy by tho user 
and the f Be has not been Camp ©red with. Thus, cordrol 35 
passes to Rg, 4{b). If no match is found after checWng 
the errtrro user ssgnasure data structure, then the entity 
is not trusted and the fBe operation is defied. 

Steps 420-426 are repeated tar each entry in the 
system signature date structure (or until a rrmtch & 40 
found). In step 422, the fUe system decrypts tho 
encrypted checksum 210 of affidavit 20$ using the pub- 
lic key of tho current system signature data structure 
entry. Ef, in step 424. the decrypted checksum matches 
the checksum determined in step 404, then the afrtdgvfi 4s 
represents an entity considered trustworthy by the sys- 
tem and the file operation is eHowed. If no match is 
found after chscteng the entire system signature data 
structure, then the entity is not trusted and the file oper- 
ation is denied- so 

Some implementations of the present invention 
also include a "defautf entry In one Of more of their ss$* 
nature data structures. For sxampjo, as shown in Fig. 3, 
entry 320 contains the entity "any" and allows the entity 
permission to read fSes. Thus, if Fig. 3 represents the ss 
user signature data structure, the user has indicated 
that he gives permission to any entity to open a tie in 
read-only mode. In this example, for such a f3e opeja- 
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son to actuafly be allowed by the file system, the system 
signature data structure must also allow fro access. In 
yet another implementation, either of fte signature data 
structures may contain a "not entity" entry, indicating 
that a certain entity is not allowed to make certain filq 
accesses {even if an "any" enfity is also present in one 
of the signature data s&uctures). 

The "type 0 f ieSd of Rg. 3 allows the signature data 
structure to reference pub&c keys stored in ertother pert 
of the system, such as In a data base or another signa- 
ture data structure stored elsewhere on the computer. 
For example, users may share a common signature 
data structure. Thus, m Fig. 3. the user has decided to 
aao*» access by the entities c*ma^ all of tho public Keys 
in "Geoffs" database. In some Imp! ementati oris, the 
user must be en entity trusted by Geoff 8 database in 
order to access pubtte keys therefrom. 

in a preferred cmbodimQm of tft© present Invention, 
tho encryption scheme used is tha Digital Signature 
Algorithm (OSA). dsscnoed in Schneier, "Applied Cryp- 
tography; Protocols, Algorithms, and Source Code tn 
C* second edition, pp. 403-435. which b herein 
incorporated by reference. In another embodiment the 
encryption scheme used fs the SHA-1 scheme. 

Cna preferred esri^imsftteffrG present ETwentton. 
one or both or tfi© ussr signature dote structure and the 
system signature dasa structure are stored on a PCM- 
CIA card or some ofrer removable storage meefium. 
Thus, the user simply inserts his PCMCIA card to per- 
een&lizQ the user amMor system signature data struc- 
tures CJ the compute? thai he & raorfdng on. In such an 
implementation, of course, the f Do system must (mow 
that foe signature tfafca structures are so stored. 

Rg. § is a flow chart of steps used to create signed 
fBes in a preferred embodiment of tha present invention, 
when the fUes are creased by the ecmpuier system 100. 
K. for example, files ore crested on another system and 
toeded cnto computer system 100 via tho internes or e 
floppy disk or other portable or networked media, the 
fUes must hove already been created and must have an 
affidavit associated theremtfi to be accepted by compu- 
ter system 100. Fig. 3, however, deals with the situation 
when the user wishes to create a file on computer sys- 
tem 100. 

tn step 502. tfie system obtains a private hey of tfie 
ent&y creating the file. This may be the user's private 
key if the user is creating the f 3e directly or if the user h 
running software that creates a ffle (eg., word process- 
ing software), in a preferred emboffiment. fre user Ss 
prompted for his private key and the user types rns pri- 
vate key into the sy&em or inserts a storage device on 
which f6s private key is stored. Alternately, private keys 
of users can be stored m a protected part of computer 
system 1 00. Alternately, a user may be required to enter 
a pin number before the system looks up the user's pri- 
vate key from a protected memory. In step H>4. the fBa 
is created end written to storage, whDe the ffle system 
maintains a running checksum of the data in the tile. A 
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"running checteum- fe a checksum that is continuously 
updated as the file Bs written. The system prevents ffle 
accesses by others vrtale the Ho £s being created. In 
soma cases, pontons of the fire may be wrfcen to an 
external storage medium during file creation. This situa- $ 
tJan occurs, for example, when the created Kid is large. 

It shouid be noted Chat a potential probfem can 
occur if data is written to an external storage device dur- 
ing file creation, but frie file creation operotkKi is not 
completed. In this case, data tvill arist on this eHlerna! to 
storage medium, but the data will not have en associ- 
ated affidavit Cn a preferred embedment, the ffle sys- 
tem is not allowed to access such files. Aborting the 
wnte/aeatoi of the file before the affidavit is created 
causes the system to tie&ray the parh'afly written ffU©. f5 

In step Scs, the f 3e system encrypte #»o checksum 
from step 504 usftig flie users private key and wrttesflie 
checksum to tho storage medium, either as a part of tfie 
file or associated with ftia ft&, depsrtcSng on the imple- 
mentation. Trots, all fBes created by tho f Hq system of 20 
the described embodiment novo on sssoc&ted affidavit 
tn a preferred embodiment, ecch time a file is written to, 
its cfcscteum must be recompute asid Its afifd&vit reca> 
cuSsted ueSng the private key of er@a£ng emit/. 
Some if^l^erfeftcns weSt until & filo is ctesd before 
recomputing the aff kfewii Again, a problem can arise Sf 
an error occurs during the write, but before the affidavit 
can be created and stored in association with the OTtt- 
ten filo. One© a fie is created, it can only ba opened or 
deleted by an entay that passes the fewc-Eex valedatlon 90 
test of Figs, 4{a) and 4(b). 

In ya, another errtoodiment fti© system allows a 
user to create two types of flies: verified and unverified 
files. Verified files are required to neve an associated 
affidavit and are validated as described sbovo for occh 35 
fSe operation. Norwerif ied files do not requfre verifica- 
tion bafore each fSe operation. 

In another preferred embedment, files can be 
opened in either "Verified" or unverified" modO- in this 
cmbodEment, the tae system should most I3?alyhava two <o 
"open* routines - one that requires verification of Tiles 
that it opens and one that does not. 

Rtes that are daarnioadsd, e g,, over tfie Internet or 
from a floppy dish: retain the affidavits that they had 
when they were received by the system must be pre- <s 
ceded and accompanied by an affidavit. 

Fig. 6 is a block diagram of another preferred 
embodiment of the present Invention in which the major- 
ity of the runtime envirenmsnt (e.g., an operating sys- 
tem or interpreter) must be verified as described above so 
before tho system can be booted. In Fig. 6, a small 
amount of program data is stored In a boot ROM 604. 
The CPU 602 loads a signature o? (ho runtime environ- 
ment and basic software for computing a checksum and 
decrypting an affidavit At boot time, the remainder of ss 
the runtime environment is loaded from secondary 
mass storage 610, along with its affidavit (which is an 
encrypted checksum). The CPU computes tfie check- 



sum of the runtime environment code as it is loaded and 
decrypts the affidavit using tho public toy horn the boot 
BOM. If tho checksum and the decrypted checksum 
match, the runtime environment toad es completed. The 
loaded runtime environment includes the checking soft* 
ware 608, wKch is used as described in F^s. 4(a), 4(b), 
end 5 cSurtng operation of the system. 

tn summary, the described embodiment of the 
present invention incorporates two or more tevate or sig- 
natures. A hie access must satisfy both levels before, ft is 
affowed bytfiefSe system. In addition, both the user and 
the system may specify mufiple trusted enfiaies that are 
allowed to perform file accesses in the system. Trusted 
entitles are specified tor the system, not cnafitebyffie 
basis. Various antitioe, ho&ever. can have various per- 
ircssions asscc&l&d therewith. 

Affrough the embctCmejtfs discussed Involved 
^Jes" a person of ordinary stall friths art will understand 
that the present invention could also be implemented in 
an object oriented ertvirenmont. 

Other embedments t#3l be apparent to those 
skilled in the art from consideration of tho sp©o!ficafon 
and pracBco of Hho rnvsxitai disclosed herein. R ts 
intended tfiafc frie cpectTteaflon and eaamptes ba consid- 
ered as exemplary ortfy, unfa a true scope cJftie inven- 
Eon befog invested by the fgBowing dem? aid 
ecjU§veJenta. 

1. A method of performing a f9€> access, comprising 
the steps, performed by a data proc essing system 
having a memory, ofc 

receiving an indication ftat an entity dssfres to 
perform a f Be access operation on a file of the 
data processing systomc 
obtaining a cryptographic affidavit of fte-file; 
chec&rcg that the cryptogn^ahic affidavit is 
acceptable in accordance with a uasr sfgnsturs 
data structure stored in fte memory; 
chaddng that the cryptographic afitdavit is 
acceptable tn accordanoa wifli the system sig- 
nature data sfructure stored in the memory; 
and 

allowing fte tile access operation when the 
cryptographic affidavit is acceptable in accord- 
ance with both the user signature data struc- 
ture and the system signature data structure. 

2. The method of claim 1, 

wherein fte receiving step includes the step 
of receiving en tm£cation that a file user wishes to 
download a fae, 

wherein fte step of obtaining a crypto- 
graphic affidavit of tho fOe includes the step of 
obtaining a cryptographic affidavit associated with 
the file and created using a private key of an entity 
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that provided Hie file, and 

wherein the first and second checking steps 
include the steps of checking whether the entity is a 
tasted entity for both the user and the system. 

5 

3. Themethodof daiml, 

wherein the receiving step includes the step 
of receiving an Indication that a ffle user wants to 
access an existing file of the data processing sys- 
tern, and to 

wherein the step of obtaining a crypto- 
graphic affidavit of the file deludes the step of 
obtaining a cryptographic affidavit associated with 
the file and created using a private tey of the fie 
user, and is 

wherein the first and second checking steps 
include the steps of checking whether the file user 
is a trusted entity for both the user and the system. 

4. A method of creating a secure file, comprising the 20 
steps, pe itemed by a data processing system hav- 
ing a memory, of: 

recejvirtg an indication that an entity desires to 

perform a file create operation on a fie of the as 

data processing system; 

obtaining a private tey of the entity; 

receiving data of the file to be created; 

determining a checksum of the file; 

encrypting the checksum using the private key; 30 

and 

creeling the file and an associated crypto- 
graphic affidavit that indudes the encrypted 
checksum. 

35 

6. A signature data structure stored in a memory of a 
data processing system, comprising: 

a first entity field storing a name of an entity 
trusted to perform a fte access; 40 
a first public key field storing a pubfic key of the 
first entity; 

a second entity field storing a name of an enfity 
trusted to perform atUe access; and 
a second public key field storing a pubSc key of *s 
the second entity 

6. The data structure of claim S» further inctuc5ng: 

a type f tdd incficating that additional public key so 
information is stored in a data base. 

7. The data structure of claim 5, further including a 
first permission field, indicating one or more types 

of file access operations that can be performed by ss 
the first entity. 

8. The data structure of claim 7, further including a 



second permission field, indicating one or more 
types of file access operations that can be per- 
formed by the second entity 

9. The data structure of claim 5, wheren at least one 
of the first and second entity held contains a value 
of 'any - , inoScating that any entity can perform the 
file access. 

10. Tho data structure of claim 5, wherein at least one 
of the first and second entity field contains a value 
of "no" and a wherein at least one of the first and 
second entity field contains a permission field, the 
entity field and the permission field together inoicat- 
Ing that no entity can perform a file access opera* 
tSon incScated ft the perrrissions field 

11. The data structure of claim 5, further comprising a 
plurality of first entity fields and first public key 
fields. 

12. The data structure of daim 11, further comprisinga 
plurality of second entity fietts and second public 
key fields. 

13. An apparatus for performing a fte aocsss, oompris- 
ing: 

a memory storing a user signature data struc- 
ture and a system signature data structure; 
a user Input portion configured to receive an 
indication that a file user desires to perform a 
fie access operation on a fHo having an associ- 
ated cryptographic affidavit; 
a checking portion configured to check that the 
cryptographic affidavit is acceptable in accord- 
ance with the user signature data structure; 
a checking portion configured to check that tfie 
cryptographic affidavit is acceptable in accord- 
ance with the system signature data structure; 
and 

a file access portion that allows the file access 
operation only when the cryptographic affidavit 
is acceptable in accordance with both the user 
signature data structure and the system signa- 
ture data structure. 

14. The apparatus of claim 13, 

wherein the user Input portion Includes a 
portion configured to receive an indication that a 
user wishes to download a file, and 

wherein the cryptographic affidavit of the file 
was created using a private key of an entity that 
provided the file, and 

wherein the first and second checking por- 
fions include a portion configured to check whether 
Ate entity is a trusted entity for both the user and the 
system. 
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15. The apparatus of datm 13. 

wherein the user input portion include? a 
portion configured to receive an indication that a tils 
user wants to access an existing fie on the data 
processing system, and 

wherein the cryptographic affidavft was cre- 
ated using a private key of the ffie user, and 

wherein the fret and second checking steps 
include the steps of checking whether the file user 
is a trusted entity tor both ihe user and the system. 

16. A computer program product, comprising: 

a computer usable medium having computer 
readable coda embodied therein tor petfbrmftg 
a secure file access, the computer program 
product comprising: 

computer readable program code devices 
configured to cause a computer to effect 
receiving an indication that an entity 
desires to perform a file access operation 
on a file cf the data processing system: 
computer readable program code devices 
configured to cause a computer to effect 
obtaining a cryptographic affidavit of the 
tie; 

computer readable program code devices 
configured to cause a computer to effect 
checking thai the cryptographic affidavit is 
acceptable in accordance with a user sig- 
nature data structure stored in the storage 
medium; 

computer readable program code devices 
configured to cause a computer to effect 
checking that the cryptographic affidavit is 
acceptable in accordance with the system 
signature data structure stored in the stor- 
age medium; and 

computer readable program code devices 
configured to cause a computer to effect 
allowing the fie access operation when the 
cryptographic affidavit is acceptable in 
accordance with both the user signature 
data structure and the system signature 
data structure. 



on a Me of the data processing system: 
computer readable program code devices 
configured to cause a computer to effect 
obtaining a private key of the entity: 
computer readable program code devices 
configured to cause a computer to effect 
receiving data of the fie to be created; 
computer readable program code devices 
configured to cause a computer to effect 
10 detetii inn m a checksum of the fZe; 

computer readable program code devices 
configured to causa a computer to effect 
encrypting the checksum using the private 
key: and 

is 

computer readable program code 
devices configured to cause a compu- 
ter to effect creating the fDe and an 
associated cryptographic affidavit that 
so includes the encrypted checksum. 



25 



as 



40 



17. A computer program product comprising: 



a computer usable medium having computer so 
readable code embodied therein for performing 
a file access, the computer program product 
comprising: 

computer readable program code devices ss 
configured to cause a computer to effect 
receiving an indication that an entity 
desires to pertorm a file access operation 
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